initial user stories #72
Conversation
|
|
||
| # USER-01 | ||
|
|
||
| As a user of Garden Linux I want to know about security issues in Garden Linux so I can operate my systems responsibly. |
There was a problem hiding this comment.
One of the things that I yet not understood is, will this be for ALL Users that GL or just SAP based users?
There was a problem hiding this comment.
I have intentionally not made this distinction here because I think there is nothing SAP specific about this requirement. I think we can have a separate class of user stories for SAP internal users if we need to, but so far I have not found a case where the needs are so different. Please let me know if you have any.
|
|
||
| ## Acceptance Criteria | ||
|
|
||
| - [ ] The user can query for known CVEs of a list packages |
There was a problem hiding this comment.
Should it not be the other way around? I think it's more important to query a release and get the CVEs back found within a given release? I might be just cherry-picking on the language side here.
There was a problem hiding this comment.
This might be a misunderstanding (and I see that the sentence is not very precise, thanks for pointing that out)
My current api draft looks like this
"Give me all CVE for Debian Bookworm": GET https://glvd.gardenlinux.io/v1/cves/debian_linux/bookworm
"Give me all CVE for packages vim and firefox-esr in Debian bookworm": GET https://glvd.gardenlinux.io/v1/cves/debian_linux/bookworm/packages/vim,firefox-esr
(passing the package list comma separated might be a bad design choice, I have not yet evaluated alternatives like passing them in the request body)
Does that make sense?
|
|
||
| # USER-09 | ||
|
|
||
| As a user of Garden Linux (container images) I want to be informed about additional issues installed packages bring. |
There was a problem hiding this comment.
I might be too much to ask for, but I would love to have a moth type of message in case a given release becomes vulnerable.
Ubuntu does this in a more gravy-ish way, by including it with the /etc/update-motd.d/ for the landscape tool. It aims to be more of a selling point, but the core of the idea would be that we can generate such type of message for the user to be informed that the current running installation is vulnerable.
Please tell me if I want overboard here.
There was a problem hiding this comment.
Sounds reasonable to me, and I'm not aware of any challenges with this yet.. This would mean that an http request needs to be done each time the motd is shown/updated, maybe caching would be good there and maybe this should be an optional feature.. but I like the idea.
Regarding the Gardener use-case of GL I think this is not super common that people login via ssh and will see the motd, but maybe we should also look into more observation tooling such as Prometheus? Just thinking about that now.
|
|
||
| # GLDEV-01 | ||
|
|
||
| As a developer of Garden Linux I want to assess the security impact of adding packages to Garden Linux images. |
There was a problem hiding this comment.
I do not quite what you are trying to do here? Is this about the mapping for a given vulnerability to our product, or the generic impact assessment of a CVE?
There was a problem hiding this comment.
This means the 'triage' thing we're currently doing. What we get is something like 'vim in versions before x may have CVE-123', and we might want to add information there like 'we manually applied a patch to resolve this', or 'we have configuration where this can't happen', or 'this is very unlikely to be an issue in the way Garden Linux is run'.
|
Here are some additional thoughts, we see right now some discussion regarding the support time for a given release. Hence, I would appreciate it if we could have an ability to see if a given release is still supported. Likewise, we had some ideas to have support with diminished qualities. Meaning: That some of the supported release would only receive updates when they are critical. I think this should also be able to be seen. |
adding user stories